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(57) Abstract: A revenue management software system (10) supports decisions to accept or deny (108) requests (100) for resource 
capacity (seats, rooms, volume/weight, air time, etc.) using control logic that accesses (102) multidimensional lookup tables in a 
threshold value server (14, 104) of price values for each resource (flight leg, hotel day, etc.). Each dimension of each lookup table 
corresponds to a variable that affects the value of the resource i.e. the ciurent time slot as one dimension and the number of available 
resources, e.g. seats, for the time slot for the other dimension. These variables are used to determine the minimum threshold value 
acceptable for the resource (102, 104). The threshold values are simmied (108) and the request is accepted or denied (108) based on 
the requested fare and the total siunmed threshold values. 
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Revenue Management System and Method 
Background of the Invention 

1 Field of the Invention 

The present invention relates in general to a revenue management system (also referred 
to as "yield management" system) for allocating resources or mventory in which a 
multidimensional lookup table of threshold values is employed for each resource as the control 
logic for dynamically adjustmg the acceptable revenue vahie for the resources as a function of 
two or more variables. 



r Description of the Prior Art 

Revenue management systems seek to maxunize the revenue generated from a fixed 
service or productive capacity by selectively accepting or denying requests for capacity. For 
example, in airlines a network of flights with a set of seats are available for sale on a given 
day, and customers request seats in advance of travel for various itineraries on the network. 
Based on the current reservations aheady accepted for each flight (alternatively, the remaining 
capacity available), the tune remaining in the sales horizon and forecasts of future demand for 
itineraries, airhnes must decide which itineraries and fare classes to accept and which to deny 
(or close out). 

These decisions are very detailed and con^Hcated to make because future demand is 
typically highly uncertain and one must evaluate con^lex tradeoffs between the current and 
fiiture value of capacity. Therefore, revenue management decisions are typically made or 
guided by a software system (revenue management system) that incorporates a variety of 
advanced statistical and mathematical methods. Revenue management is widely used in the 
airUne, hotel and car-rental industries and is spreading to the energy, natural gas pipehnes, 
broadcasting, shipping, sports, entertainment facihties, manufacturing, equipment leasing and 
cargo mdustries. Indeed, the practice is appUcable in any mdustry that has limited short-term 
capacity flexibility and variable demand. 

A variety of mathematical models have been proposed to solve the problem of which 
requests to accept or deny based on current capacity and forecasts of future demand. 
However, regardless of the mathematical model and assumptions used, revenue management 
software systems ultunately need an internal control logic to implement the accept/deny 
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recominendations. To date, two control schemes have been developed to knplement 
accept/deny decisions: nested capacity allocation and static-bid prices. 

The oldest and most widespread approach to in^lementing accept/deny decisions is to 
use nested capacity allocations (also called 'l)ooking limits") on the various classes and rates 
5 for the capacity. This is the approach used in the early work of Littlewood (1972) on discount 
fare class allocation. It was popularized m the academic Uterature by Belobaba (1987, 1989). 
This is the approach used in many of the older commercial revenue management systems. 

One exan^)le of a nested capacity allocation scheme is known as Single-resoxrrce 
Nested Allocations. This approach was origmally developed to allocate capacity of a single 
10 resource, for exan^le a single flight leg, to one of n possible demand classes (fare- classes in 
airUne industry). The control logic works as follows: 

Let c be the total capacity. Let the net revenues of the n demand types be denoted/ 
and assume without loss of generality that these demand classes are mdexed so that fj >f2 
>Y>f„ . A so-called nested allocation logic specifies values (protection levels) Xj, x^, Y, x„that 
15 satisfy 

< x„,j<Y< x„=c. 

Let J denote the remaining capacity. The logic is to accept demand class i if and only if 

y>Xi i=l,Zn 

That is, demand class i is accepted if the remainiag capacity exceeds the protection level, x,, 
20 for that class. An alternative and more popular method to inclement this same logic is to 
define a set of booking limits, 6^, usmg 
bi^ c B Xf. 

Let r denote the number of reservations on hand (r==c-y). In this case, the logic is to accept a 
request fi^om demand type / if and only if 

25 r< b, 

That is, accept demand class / if and only if the number of reservations on hand is less than the 
booking Hmit for demand class /. The maxunum available capacity for any class / is usually 
referred to as the authorization level and is defined by 

a, = max{b^ B r, 0} 

30 These are the control logic schemes described in Belobaba (1987, 1989) and Brumelle et al 

(1990, 1993) and elsewhere. Belobaba (1987, 1988) describes some approximate methods for 
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setting aUocation parameters while Brumelle et al. (1990, 1993) describe exact algorithms for 
coirq)utiiig the parameters. 

Whatever method is used to confute the parameter values, the nested aUocation 
stmcture has some distmct advantages. Namely, it has the desirable featiire that a small 

5 number of control parameters {n booking limits or protection levels) can be calculated once by 
an optimization module. Then, the accept/deny decisions dynamically adjust as available 
capacity changes. That is, as more capacity is sold, more demand classes are "closed out" as 
booking limits are reached. Altematively, when customers cancel, more capacity becomes 
available and some demand classes may "open up" as the available capacity exceeds their 

10 booking limits. In this way, the nested allocation stmcture adjusts to the evolving capacity 
conditions. 

While the nested allocation scheme works well for a single resoxu-ce, extending it to 
allocate capacity for multiple resources (legs of a flight network for example) is somewhat 
problematic. For exan:q)le, it is not clear how to rank demand class that use different 

15 resources, so the nested stmcture becomes diflScuh to apply. Also, if allocations are defined 
for all revenue values and every combination of resources, the number of allocation values 
requhed becomes too large for practical ktq)lementation in a reservation system 

To avoid this large number of allocation values, most approaches for extendmg nested 
allocation control logic to networks involve converting the multiple-resource allocation 

20 problem into a collection of single-resource problems and then applying the controls generated 
by this collection of smgle-resource allocation problems. 

This is accompUshed as foUows: Fust, the revenue values for a multiple resource 
request are adjusted by quantities that reflect the displacement value of the other resources 
used by the request. These displacement-adjusted fare values are then used to compute 

25 nested allocations for each leg. Displacement adjusted values are often clustered into 'Virtual 
classes" first to reduce the number of classes involved. This process of creating virtual classes 
is caUed indexing by Smith et al. (1992). See WilHamson (1992) and Vmod (1990) for fiirther 
discussion of this approach, which also goes by the name of virtual nesting (Smith et al. 
1992). 

30 These displacement-adjusted values have some advantages: They require only a smaU 

number of control variables and the nested allocation stmcture maintams the favorable 
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property of adjusting accept/deny decisions as available capacity changes. They also provide a 
maximiuu available capacity for each demand class through the authorization levels. 
However, the displacement adjustment process and clustering into virtual classes adds a 
significant amomt of complexity to the control logic. This complexity has made their 
5 implementation prohibitive for most users of revenue management systems. 

An alternative control logic for multiple-resource problems is to use what are called 
resource bid prices. This idea was first proposed by Simpson (1989) and was extensively 
investigated in the Ph.D. dissertation of Williamson (1992). See also Curry (1992) and 
Philhps (1994). Let m denote the number of resources to allocate. In a bid price control 
10 scheme, values (bid prices) /=7,..,m are set for each of the m resources. Suppose a request 
comes in to purchase a set of resources {ii,..JJ. Then a bid price control would accept the 
request of net revenue value / if and only if 
/>v,, + 7 + 

That is, a request is accepted if and only if the fare exceeds the sum of the bid prices of 
15 all the capacity units required to satisfy the demand. The interpretation of the values v. is that 
they represent the threshold value of resource capacity. Again, a variety of optimization 
methods and approximations have been proposed for determining the bid price parameter 
values. (See Sinq)son (1989) and Williamson (1992).) 

The advantage of the bid price logic is that it requires very few parameters, one value 
20 for each resource, and does not require separate displacement adjustment and indexing steps. 

The main weakness is that the logic is not dynamic. Specifically, the accept/deny decisions do 
not change if remaining capacity fluctuates and/or the time remaining in the horizon changes. 
As a result, the bid price values v,. must be updated very fi-equently (usually by re-forecasting 
and re-optimizing a mathematical model) to ensure that they track changes in the available 
25 capacity among all resoiu-ces. Ideally, this updating of bid-prices has to be done after each 
booking or cancellations (or change in the remaining resource) which is prohibitive to do 
operationally. They also do not provide any indication of the maximmn available capacity for 
a given demand class and cannot be used directly to compute authorization levels. 
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SximTnary of the Invention 
In view of the foregoing, a need exists for a revenue management scheme that is robust 
enough to accommodate allocation of multiple resources, each of which is dependent on 
multiple variables, yet which possesses sin^Ucity and ease of ia^lementation. The present 
5 invention satisfies this need through use of multidimensional lookup tables that are en:q)loyed 
to manage revenue fi*om each resource as a function of a pluraUty of variables (such as time 
and capacity, for exan^le). The main benefit of the approach is to add a high degree of 
flexibility and dynamic adjustment abiUty to the control logic while keeping the number of 
controls used to within acceptable operational limits, 

10 In this control logic, a multidimensional table (array) of threshold values is specified 

for each resource. Each dimension (axis) of the table corresponds to a variable that affects the 
threshold value of the resource. In an exemplary two-dimensional table for determining 
threshold values for travel reservations, one dimension of the table, is selected to index the 
niunber of remaining time periods and the other, x, is selected to index the remaining capacity 

1 5 for the desired reservation. 

The lookup tables are en^loyed in the method of the present invention in the following 
manner. First, a request for a resource, or a combiaation of resources, is received in a system 
con^uter either from another system or conq)uter, or from an operator entering the request 
manually. The request not only identifies each of the resources, but also identifies a revenue 

20 value for the resources. For exanq)le, a multiple flight leg itinerary for an airline reservation 
represents a multiple resource allocation scenario, with each leg of the flight representing one 
of the resources, and the entered or calculated expected fare for the itmerary representing the 
revenue value. 

Once the request has been entered, the con^uter accesses the lookup table for each 
25 resource identified in the request. The control logic for using the tables is that the threshold 

value used at any point in time for any given resource is obtained by looking m the appropriate 
place in the table. As the variables defining the dimensions (e.g., available capacity and the 
time remaining) of the table change, the threshold value in the table can adapt. After the 
threshold values for the present combination of variables are extracted from the tables, the net 
30 revenue of a request is con:q)ared to the sum of the threshold values of the resources required 
by the request. If the net revenue exceeds or equals the total of the threshold values, then it is 
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accepted; if it does not, it is rejected. The ability of the threshold values for each resource to 
change as the variables (e.g., remaining capacity and remaining time) change, adds robustness 
and stabihty to the sale process - for instance, it offers protection that a sudden unexpected 
surge in demand at a low fare would not result in too much inventory being sold at a too low a 
5 rate (a problem with the static bid-price controls); at the same time, a persistent and 

inconsistent (with the forecasts) failure of demand to appear between re-forecasting re- 
optimizations would result in the current threshold value to automatically go down, a feature 
not present either in the allocation controls or static bid-price controls. 

Thus, through this dynamic threshold value control logic, a considerable amount of 

10 dynamic adjustment capabihty can be achieved ia a revenue or yield management system. At 
the same time, it preserves sin^licity and speed, and requires only a modest number of 
control parameters, namely one table for each resource. Further, the present invention offers 
significant generalization in the degree of control, as well as superior robustness with respect 
to forecasting errors and operational factors compared to the current control logic used to 

15 control iaventory in revenue management systems. 

Another major advantage of the tables is that they can be used to quickly compute 
maximum allocations for each demand type. This is achieved by successively adding the 
threshold values and then decrementing each resource's capacity value until the sum of the 
threshold values exceeds the net revenue of the demand type. The amount by which the 

20 capacity was decremented gives the maximum capacity allocation for the demand type. This 
logic foUows singly by considering how many requests of a given type would be accepted in 
sequence. 

This decision logic reqtiires only a simple table lookup (database query or memory 
access) operation, which is very fast. It is capable of mimicking the decisions of nested 

25 allocation and traditional bid price controls, but provides additional flexibility to allow the 

threshold values to adjust to capacity and time changes. It also allows for easy calculation of 
maximum available capacity for any given type of request. Moreover, since the lookup table 
logically separates the optimization modules and reservation-acceptance modules, it provides 
ircproved additional robustness in the operation of revenue management systems. Also, it 

30 simulates frequent re- optimizations and is highly resilient to forecasting errors and bias in the 
forecasts. 
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Brief Description of the Drawings 
The features and advantages of the present invention will become apparent from the 
following detailed description of a preferred embodiment thereof^ taken in conjunction with 
the accompanying drawings, in which: 
5 FIG. I is a schematic diagram of networked conq)uter system that can be en:q)loyed to 

iaq)lement the preferred embodiment of the present invention; 

FIGrs. 2A and 2B are example two dimensional threshold value tables that are 
errq)loyed to illustrate the fimctionaUty of the preferred embodiment; 

FIG. 3 is a flow chart illustrating the logic used in an exerc^lary application of the 
10 preferred embodiment for processing requests for seat reservations usiag the threshold value 
tables; and 

FIG. 4 is a flow chart illustrating the logic used in an exen:5)lary appUcation of the 
preferred embodiment for determining the maximum number of seats available at a 
predetermined fare using the threshold value tables. 

15 Detailed Description of a Preferred Embodiment 

With reference first to FIG. 1, a revenue management system 10 is illustrated that is 
en^iloyed for inq)lementing a first preferred embodiment of the present invention for managing 
reservations for a Bmited capacity resource, such as seats on an airline flight. The system 10 
includes a pluraUty of networked con:q)uters 12, each of which commxinicates with a threshold 

20 value table server 14. Iq this embodiment of the invention, the threshold value table server 14 
manages access to a plurality of lookup tables referred to as dynamic threshold value tables, 
each of which contains threshold values for a resource as a fimction of two or more variables. 
A reservation system con5)uter 16 is interfaced to the threshold value table server 14 which 
handles reservation bookings requested through the con^uters 12, and manages the 

25 reservation yield. Finally, a database 18 is provided for maintaining historical records of all 
processed reservations. 

In the operation of the system 10, a system operator enters a request for either a 
reservation or an authorization level for a particular itinerary into one of the conq)uters 12. In 
response, the bid-price table server 14 accesses all appUcable threshold value tables for the 

30 itinerary, and supplies them to the reservation system computer 16 for processing. In the case 
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of an itinerary consisting of multiple airline flight legs, a threshold value table will be provided 
for each flight leg. In this exan^le, as will be discussed in greater detail below in conjunction 
with FIGs. 2A-2B, the reservation system con5)uter 16 en^loys the threshold value tables to 
determine acceptable price values for each flight leg of the requested itinerary. The sum of 
5 these is con[q)ared to the net revenue expected from the use of the resources for the 

reservation system to determine whether the reservation wiU be accepted and/or how many 
reservations at the given revenue value will be accepted. The net revenue value is received by 
the system either by being entered by the system operator or another computer system. In 
addition, this value may be calculated by another system. 

10 To better understand the threshold value tables and their use, reference is made to 

FIGs. 2A and 2B which illustrate two exarq)les of such tables for two undefined resources, 
Resource 1 and Resource 2. Each of the tables conq)rises a two-dimensional table (array) of 
numerical values that is specified for each resource. One dimension or axis of the table, 
indexes the number of remaining time periods available for reserving the resource, and the 

15 other, x, indexes the remaining capacity for the resomce. The shaded area in each of the 

tables represent regions where a revenue value of 80 and 25 for Resource 1 and Resource 2, 
respectively, will be accepted for the particular combination of t and x 

The threshold value used at any point in time for any given resource is obtained by 
looking in the appropriate place m the table. For exarcple, consider Table 1 of FIG. 2A. If the 

20 remaining capacity for this resource is 3 units and the remaining time index is 7, then the table 
value is 69. 6 1 . Thus, the threshold value in effect under these conditions is 69. 9 1 , If the 
available capacity changes or the time remaining changes, the threshold value in the table can 
adapt. Continuing the example, if the remaining time index is 7 and 2 of the 3 units of 
capacity are sold, one imit of capacity remams. In this case, the value in Table 1 of FIG. 2A 

25 mdicates that the threshold value has increased to 1 16.6. 

As discussed above m conjunction with FIG. 1, the reservation system conq)uter 16 
compares the net revenue of a request to the sum of the threshold values of the resoiu^ces 
required by the request. If the net revenue exceeds or equals the total of the threshold values, 
then it is accepted; if it does not, it is rejected. For exanq)le, suppose the time index remaining 

30 is 7, the Table 1 resource has 3 units of capacity remaining and the Table 2 resource has 4 

units of capacity remaining. The acceptable threshold values for each resource are then 69.91 
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and 4.001, respectively. If a request is received that requires both resources with a net 
revenue of 70, the corq)uter 16 corrq)ares it to the sum 69.91 + 4.001 = 73.911. Since 70 < 
73.991, the request is rejected. 

The diflference between this process and conventional bid price logic is that the 
5 threshold value for each resource changes as remaining capacity and re mainin g time change. 
For exanq)le, if there is a cancellation of a previously accepted request for the resource in 
Table 1 so that the remaming capacity increases to 4, the new sum becomes 
34.71 + 4.001 = 38.781. In this case, a request with net revenue of 70 will be accepted. After 
acceptmg this request, however, the remaining capacity of resource 1 would be 3 again and 

10 the threshold value would rise to its previous value of 69.9 1. Therefore, another request of 
the same type would be rejected if it arrived next. 

The logic of this decision rule is diagramed in the flow chart of FIG. 3 for the specific 
example where each resource is a seat on a flight leg of a requested itinerary /, and the 
threshold values in each lookup table represent minimum prices that will be accepted for the 

15 corresponding flight leg. First, at step 100, the seat reservation request is received fi*om a 

system operator or another system, and identifies the itinerary /, as well as the fare^ which the 
passenger wishes to pay. Next, at step 102, the reservation system computer 16 performs a 
lookup operation for the current threshold value for each flight leg m the itinerary. This is 
accompUshed by sending the current time and current capacity vector to the threshold value 

20 table server 14. In response, at step 104, the threshold value table server 14 accesses the 
threshold value table for each of the flight legs, and retrieves the price value for each leg 
corresponding to the time and capacity vector. The threshold values for aU of the legs ia the 
itinerary are then returned to the reservation system con:q)uter 16. Finally, at step 106, the 
reservation system corE5)uter sums all of the retrieved threshold values, and, at step 108, 

25 conqjares the sum to the requested fare / If/is greater than or equal to the sum, the 

reservation is accepted; otherwise, it is rejected. If the reservation is accepted, a record of the 
reservation is sent to the database 18 so that the current capacity will be properly adjusted for 
the next reservation request requiring any of the legs m the itinerary / . 

A second major advantage of the dynamically adjustable threshold value tables is that 

30 they can be used to quickly con:q)ute maxiaium allocations for each demand type. This is 

achieved by successively adding the threshold values and then decrementing each resource's 
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capacity value until the sum of the threshold values exceeds the net revenue of the demand 
type. The amount by which the capacity was decremented gives the maximum capacity 
allocation for the demand type. This logic follows sm^ly by considering how many requests 
of a given type would be accepted in sequence. The logic is diagramed in the flow chart in 
5 FIG. 4, and an exarr^le of this authorization level calculation follows. First, at step 200, 
a system operator enters a request for the maxunum possible seat reservations that will be 
accepted for an itinerary / at a fare per seat of no more than / A count k is initialized to 0 to 
keep track of the total number of seats available at / Next, at step 202, the process of FIG. 3 
is carried out to determine whether a first seat reservation will be accepted at fare / for the 

10 current capacity and time vector. Assuming it wiH be accepted, k is incremented by 1 at step 
204, and step 202 is repeated, but this time with the current used capacity incremented by 1, 
and the current available capacity decremented by 1. This process is repeated mtil the sum of 
the threshold values is greater than or equal to the fare / for the (k-\-lJth request. When this 
occurs, the value k is determined at step 206 to be the number of reservations that will be 

15 accepted at the fare / for the itinerary /, and this value is returned to the reservation/booking 
system. 

To illustrate this process more clearly, the tables in FIGs. 2A and 2B may be employed 
in the following exarc5)le. Consider Tables 1 and 2 with 10 units of time remaining, with 
Resource 1 having 6 tmits of capacity remaining (threshold value of 19.95) and with Resource 

20 2 having 4 units remaining (threshold value of 14.5). Suppose it is desired that an 

authorization level be computed for a demand class that has a net revenue of 160 and requires 
both Resoiuces 1 and 2. 

Coiiq)aring 160 to the current threshold values of 19.95 + 14.50 = 34.45, the first 
request of this type would be accepted. Proceeding, the capacity values of Resources 1 and 2 

25 are decremented to 5 and 3, respectively, which yield threshold values of 44.03 and 38.66, 
respectively. The new sum of the prices is 44.03+38.66= 82.69. Since this sum is still less 
than 160, a second request of this type would be accepted. Continuing m this manner, it is 
determined that up to 3 units of the 160 demand type can be accepted without the threshold 
value total exceeding 160. However, the fourth request of this type would push the total 

30 threshold value firom the tables up to 207.03, so that this request would be rejected. Thus, the 
maximum capacity that would be sold B the authorization level B is 3 units. In this way, an 
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authorization level can be quickly con:5)uted for any demand type with any associated net 
revenue and requiring any arbitrary set of resources. 

Although the foregoing exartqples illustrate the process of the present invention, it will 
of course be understood that the invention is not limited to any particular appUcation. On the 
contrary, the threshold value tables can be used for managing any type of resource reservation 
application where the threshold value of one or more resources varies as a function of two or 
more variables. For example, although the invention is particularly useful for managing 
transportation and accommodation related sales or reservations (e.g., airline, train, bus and 
hotel reservations, etc.), the invention may also be employed for managing cargo inventory. 
In this appUcation, three-dimensional threshold value lookup tables are preferably employed, 
with one dimension for each of the following three variables that have an iofluence on current 
acceptable threshold values: time, weight and volume. Fxirther, although the invention is 
particularly suited for determining acceptable monetary values for travel reservations, the 
lookup tables can be used for determining any type of acceptable threshold value that 
fluctuates as a ftmction of two or more variables. 

Other appUcations of the present invention include allocation of advertising time slots 
and allocation of tickets to facihties (sports, theaters, cinema, amusement parks, resorts). In 
the case of advertising time slots, the dimensions for the lookup table will be remaining 
available time- slots, and the time of broadcast for the media industry (television, radio, print 
media, Intemet advertising, etc.). In the case of tickets to facUities, the dimensions for the 
lookup table Avill be time remaining until the scheduled event, and number of available seats 
remaining in each class. 

In conclusion, the present invention, through use of the dynamically adjustable 
threshold value tables, provides a vastly in:q)roved and robust revenue or yield management 
system and method that can easily accommodate changes in resource threshold values in 
response to many variables, without requiring corrqjlex con[5)uter software. Although the 
present invention has been disclosed in terms of a preferred embodiment and variations 
thereon, it will be imderstood that nxmierous additional variations and modifications could be 
made thereto without departmg from the scope of the invention as set forth in the following 
claims. 
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Claims 

1. A conq)uter iii5)lemented method for managing allocation of a resource con:q)rising 
the steps of: 

a) recehing a request for a first resource in a revenue management system computer; 
5 b) accessing a multidimensional lookup table with said coii5)uter, said table including 

1) an axis for each dimension defining a corresponding one of a plurality of variables that 
affects an acceptable threshold value for said resource ; and 2) a pluraKty of threshold value 
entries for said resource, one for each of a pluraUty of combmations of values for said 
variables; 

10 c) determining a present value for each of said variables; 

d) retrieving a threshold value entry fi:om said lookup table corresponding to a 
combination of said variables corresponding to the present value for each of said variables; 

e) comparing the selected threshold value entry to an expected net revenue value for 
said resource; and 

15 f) if the expected net revenue value is greater than or equal to the selected threshold 

value entry, generating an indication that the request for the resource will be accepted. 

2. The method of clahn 1, wherein said step of receiving a request fiirther comprises 
receiving a request for a pluraUty of resources; said step of accessing firrther con:^)rises 

20 accessing a pluraUty of said lookup tables, one for each of said resources; said step of 

con:q)aring further con^rises con5)aring a sum of the threshold value entries for each of said 
resources to a combined net revenue value for the pluraUty of the resources; and, said step of 
generating further con^rises generatmg an indication that the request for the resources will be 
accepted if the net revenue value is greater than or equal to the sum of the selected threshold 

25 value entries. 

3. The method of claim 2, wherein one dimension of each of said tables comprises 
capacity for the corresponding resource, and the step of generatmg an indication that the 
request for the resources wiU be accepted if the revenue value is greater than or equal to the 

30 sum of the selected threshold value entries further con^rises the steps of: 

1) if the revenue value is greater than or equal to the sum of the selected 
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threshold value entries, then: 

i) deterniining that a request for said resources will be accepted at the 
revenue value for the current combination of values for said variables by mcrementing 
a count for said number of acceptable requests by one unit; 

ii) adjusting the current values of said variables as necessary to 
accommodate the reduction of available capacity of each of said resources by one unit; 
and 

iii) returning to step c) for the adjusted current values of said variables 
to determine whether another request for said resources will be accepted at the 
revenue value; 

2) if the revenue value is less than the sum of the threshold value entries in said 
lookup tables corresponding to the current combination of values for said variables, then 
outputting the value of said count as the total number of requests that will be presently 
accepted for said resources at said revenue value, 

4. The method of claim 1, wherein one dimension of said table comprises capacity for 
the resource, and the step of generating an indication that the request for the resoxirce will be 
accepted if the revenue value is greater than or equal to the selected threshold value entry 
fiirther comprises the steps of: 

1) if the revenue value is greater than or equal to the selected threshold value 

entry, then: 

i) determining that a request for said resource will be accepted at the 
revenue value for the current combination of values for said variables by incrementing 
a count for said niunber of acceptable requests by one imit; 

ii) adjusting the current values of said variables as necessary to 
accommodate the reduction of available capacity of said resource by one unit; and 

iii) returning to step c) for the adjusted current values of said variables 
to determine whether another request for said resource will be accepted at the revenue 
value; 

2) if the revenue value is less than the threshold value entry in said lookup table 
corresponding to the current combination of values for said variables, then outputting the 
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value of said count as the total number of requests that will be presently accepted for said 
resource at said revenue value. 



5. The method of claim 1, wherein said resource conq)rises seats on a means of 
transportation for a trip to a selected destination, and said dimensions comprise remaining 
available seating capacity and remaining time until said trip is scheduled to commence. 

6. The method of claim 1, wherein said resource comprises cargo space on or means 
of transportation for a trip to a selected destination, and said dimensions con5)rise remaining 
available cargo weight, remaining available cargo volume and time remaining until said trip is 
scheduled to commence. 

7. The method of claim 2, whereia each of said resources conq)rises seats on a means 
of transportation for one of a pluraUty of legs of a trip to a selected destmation, and said 
dimensions con5}rise remaining available seating capacity and remaining time until said trip is 
schedtiled to commence. 

8. The method of claim 2, wherein each of said resoiuces cort]5)rises cargo space on 
means of transportation for one of a pluraUty of legs of a trip to a selected destination, and 
said dimensions con^rise remaining available cargo weight, remaining available cargo volume 
and time remaining imtil said trip is scheduled to commence. 

9. The method of claim 1, wherein said resource comprises advertising time slots and 
said dimensions con^rise remaining available time-slots and the time of broadcast for the 
advertising. 

10. The method of claim 2, wherein said resource comprises advertising time slots for 
one of a pluraUty of days and said dimensions corr^rise remaining available time-slots and the 
time of broadcast for advertising. 

11. The method of claim 1, wherein said resource con5)rises tickets to faciUties for at 
least one scheduled event, and said dimensions comprise thne remaining until the scheduled 
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12. The method of claim 2, wherein said resources con^rise tickets to faciHties for a 
pluraUty of seats for a plurafity of scheduled events, and said dhnensions con^rise time 

5 remaining until the scheduled events, and the mrmber of seats remaining in each of one or 
more classes for the events. 

13. The method of claim 1, wherein said threshold values in said lookup table 
represent the minimum price that will be accepted for said resource, said price varying as a 

10 fimction of said pluraUty of variables defining said dimensions of said lookup table. 

14. The method of claim 2, wherein said threshold values in said lookup tables 
represent the Tninimnm prices that will be accepted for each of said resoxurces, said prices 
varying as a function of said pluraUty of variables defining said dimensions of said lookup 

15 tables. 

15. A system for managing aUocation of a resource comprismg; 

a) a computer for processing requests for aUocation of at least a first resource; 

b) at least a first lookup table interfaced to said con:q)uter containing a pluraUty of 
acceptable threshold value entries for said resource, one entry for each combination of values 

20 of a plxiraUty of variables that have an affect on the acceptable threshold value for said 
resource; and 

c) means in said con:5)uter for: 

1) receiving a request for said resomrce; 

2) accessing said lookup table to retrieve a current acceptable threshold value 
25 for said resource based on a current combination of values for said variables; 

3) con]q)aring the retrieved threshold value fi-om said lookup table to a net 

revenue value for said request; and 

4) generating an indication that the request wiU be accepted if the net revenue 
value for the resource is greater than or equal to the threshold value in the lookup table, and 

30 that the request wiU be rejected otherwise. 
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16. The system of claim 15, wherein said computer processes requests for allocation 
of a plurality of resources, and said system further con^rises a plurality of said lookup tables 
interfaced to said con^uter, each containing a pluraUty of acceptable threshold value entries 
for a corresponding one of said resources; and said means in said computer for receiving, 
accessing, con^aring and generating fiirther conqjrises means for: 

1) receiving a request for said resources; 

2) accessing said lookup tables to retrieve current acceptable threshold values 
for each of said resources based on current combinations of values for said variables; 

3) corc5)armg a sxma of the retrieved threshold values from said lookup tables to 
a net revenue value for said request; and 

4) generating an indication that the request will be accepted if the net revenue 
value for the resource is greater than or equal to the sum of the threshold values m the lookup 
tables, and that the request will be rejected otherwise. 

17. The system of claim 16, wherein one dimension of each of said tables conq)rises 
capacity for the corresponding resource, and said means in said computer for receiving, 
accessing, conq)aring and generating fiirther comprises means for determining a total number 
of requests for said resources that will be accepted at said net revenue value. 

18. The system of clann 15, wherem one dimension said table comprises capacity for 
said resource, and said means in said conjputer for receiving, accessing, comparing and 
generatmg fiirther comprises means for determining a total number of requests for said 
resource that will be accepted at said net revenue value. 

19. The system of claim 15, wherein the threshold values in said lookup table 
represent minimum acceptable prices for said resource as a fimction of said variables, and said 
variables are selected from the group comprising remaining capacity, remaining tune, 
remaining volume and remaining weight for said resource. 

20. The system of claim 16, wherein the threshold values in said lookup tables 
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represent Tninimiim acceptable prices for said resources as a function of said variables, and 
said variables are selected from the group con:q)rishig remaining capacity^ remaining time, 
remaining volmne and remaining weight for said resources. 
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